[rqd] [cuegui] Add support for Loki for frame logs #1577
Conversation
…vided by ch.qos.logback:logback-classic and causing conflict
Add loki details to jobs in database using extra fields
# Conflicts: # cuebot/src/main/java/com/imageworks/spcue/dao/postgres/FrameDaoJdbc.java
|
Please remove the "Draft" status when this is ready for review |
lithorus
requested review from
bcipriano,
DiegoTavares and
ramonfigueiredo
as code owners
# Conflicts: # cuebot/src/main/java/com/imageworks/spcue/dao/postgres/DispatchQuery.java # cuebot/src/main/java/com/imageworks/spcue/dao/postgres/FrameDaoJdbc.java
| public Boolean logLokiEnabled; | ||
| public String logLokiURL; |
| alter table job | ||
| add b_loki_enabled bool; | ||
|
|
||
| alter table job | ||
| add str_loki_url varchar(256); |
There was a problem hiding this comment.
I'm not completely sold on the idea of every job having these set. I agree runFrame is the best place to communicate this value from cuebot to rqd, but having to store this on the job table doesn't make too much sense to me.
prepareRqdRunFrame on dispatch support could read the logpath directly from jobLogUtil, keeping the database out of the loop
| # Loki | ||
| log.loki.enabled=false | ||
| log.loki.url=http://localhost/loki/api |
There was a problem hiding this comment.
Please elaborate on the docs here. I would add:
- link to a tutorial on how to setup loki
- quick description of what happens when this feature is on
- what to expect if an invalid url is provided
There was a problem hiding this comment.
Have added small description. Will add general Loki documentaion on opencue.io
|
Should buffering be part of this PR? Or should it be part of a more generic system for buffering log writes? |
# Conflicts: # VERSION.in # requirements.txt
Link the Issue(s) this Pull Request is related to.
#1571
Summarize your change.
This adds the ability to use loki as the backend for frame logs in rqd. It also adds a new plugin/widget in cuegui to read the logs from the loki server.
This enables logs files to not be bound by a single namespace and also adds the potential to also store telemetry about the frame.
This is still on an experimental stage and any inputs are appreciated.
Screenshot of new widget :
Not yet implemented :